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A TOKEN DELIVERY SYSTEM 

FIELD OF THE INVENTION 

5 The present invention relates to a system and a process for use in validation, and in 

particular to a system that facilitates the distribution and use of virtual tokens for products, 
such as goods, services, discounts and/or exchange offers. 

BACKGROUND OF THE INVENTION 

10 

Electronic, '^virtual" tickets, tokens or vouchers have been developed in various forms 
to enable the provision of goods or services. The tokens may entitle the holder to a variety of 
different products, such as access to transport facilities and admission to entert£iinment or 
sporting events, hi situations where the purchaser of goods or services wishes to redeem a 

1 5 virtual "proof of purchase" token in person, existing systems require the purchaser to print a 
physical token and exchange it for the good or service. This eliminates the need for the 
provider to generate a physical token and deliver it to the purchaser, but it still requires a 
physiceil token to be generated and maintained by the purchaser. The tokens are also static in 
that they are redeemed for a predetemiined instance of a particular product. It is desired 

20 therefore to provide a system and a process that alleviates these restrictions, or at least 
provides a useful alternative. 

SUMMARY OF THE INVENTION 

25 In accordance with the present invention there is provided a token process, including 

sending a virtual token from a network device to a handheld device to generate a machine- 
readable representation of the token in the handheld device. 

The present invention also provides a token process, including downloading a virtual 
30 token from a network device to a handheld device to generate a machine-readable 
representation of the token on the handheld device, so that the representation may be read with 
a reading device to validate said token; * 
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The present invention also provides a token process including: 
storing transaction data for purchase of a product; 
generating a token for redemption of said product; 
5 providing access to said token over a communications network; and 

sending said token to a handheld device on receipt of a request for said token, 
said token being readable from said handheld device by a reading device at point of 
provision of said product. 

10 The present invention also provides a token system including: 

a transaction server accessed over a commimications network, said server storing 
transaction data for pxirchase of a product, and generating a token for redemption of said 
product, said token being accessible over said network from said server such that said token 
is sent to a handheld device on receipt of a valid request for said token from said handheld 

15 device. 

The present invention also provides a handheld device including wireless 
communication means for receiving ticket data, said ticket data adapted to generate a visual 
display on said handheld device readable by a reading device to redeem a product 
20 corresponding to said ticket. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Preferred embodiments of the present invention are hereinafter described, by way of 
25 example only, with reference to the accompanying drawings, wherein: 

Figure 1 is a block diagram of a prefenred embodiment of a token transmission system 
of the token system; 

Figure 2 is a block diagram of a preferred embodiment of a reading system of the token 
system; 

30 Figure 3 shows a WAP mobile telephone of the token system; and 

Figures 4, 5 and 6 are flow diagrams of a token process executed by the system. 
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A validation system includes a token transmission system as shown in Figure 1 and a 
reading system as shown in Figure 2. The transmission system transmits virtual tokens to a 
handheld device 2, such as Wireless Application Protocol (WAP) capable mobile telq)hone. 
The transmission system includes a database S on a server 6 which is connected to the WAP 
5 telephone 2 via the Litemet or mobile data networks, constituting a communication network 
4. 

The server 6 fiirther includes a transaction module 8 that operates to store, maintain 
and process data held in the database 5. The server 6 may be a standard computer system, such 

10 as a Sun Microsystems server, having software stored thereon so that the server 6 is able to 
operate as a web and/or WAP server, and together also with software to provide the transaction 
module 8 and the database 5. Alternatively, the server 6 may include dedicated hardware 
circuits to execute at least some of the steps of the software components. The hardware and 
software components of the server 6 may also be distributed over a communications network, 

15 such as the Internet 4. The reading system reads and validates virtual tokens and includes the 
WAP telephone 2, a barcode reader 12 and an entry gate 16 connected to a networked 
computer 14 having a read module 1 8. The computer 14 can be connected through the Intemet 
4 to the server 6. The entry gate 16 may be a physical gate or a device operated by a person 
which includes the reader 12. 

20 

A person with the WAP-capable mobile telephone 2 who wishes to attend an event 
can, at some time prior to the event, purchase a virtual token for the event The token could 
be purchased over the Intemet using a computer or using the WAP telephone using most 
transaction methods. For example, the person may simply dial a 1-900 service. However, a 
25 case shall be described below wherein the token is purchased using a web browser, as shown 
in Figure 4. The cost of the token is debited from a line of credit such as a telephone or credit 
card account, or a pre-paid accoimt The provide of the validation system may charge a 
percentage of the purchase cost. 

30 The transaction begins when the ciistomer contacts the event provider, which occurs when the 
customer accesses flie provider's web site at step 32. The customer provides event and accoimt 
details to the provider at step 36. The account details may include a credit card or other 
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account number, togettier with siq>porting data sudi as a personal identification number (PIN), 
password, or the credit card name and expiry details. After the transaction is approved at step 
38, a transaction identifier is generated by the traiisaction module 8, and at step 42 this is 
recorded in the database 5 along with other transaction details including event and 
5 identification data. The identification data is unique to the purchaser and includes tiie mobile 
telephone number and/or some oflier password or identification code. 

When the person purchases the token as described above, the server 6 generates a unique 
Universal Resource Locator (URL) for the token at step 44 and provides it to the customer at 
10 step 46. For easy access, this URL may be stored in the phone 2 by simply adding the URL to 
the browser's bookmarks. 



Before the person attends the event, they access the URL with application software on the 
phone, such as the phone's browser software at step 52, as shown in Figure 5. When the server 

15 6 receives a request to the URL, the server 6 first verifies the identity of the purchaser at step 
54 using the identification data described above and data provided with the request, such as 
web Cookies or call record data within the communications network 4. If the identification is 
positive, the server 6 generates a new token number and corresponding barcode image at step 
56, and the token number is stored in the database 5 at step 58. The barcode image is 

20 transferred to the phone 2 by WAP at step 60 so that the barcode is reproduced on the visual 
display of the phone 2, allowing the display to be read by a barcode reader. This is particularly 
advantageous as the displayed barcode can be read by existing barcode readers and the 
mfiastructure supporting the readers does not have to be built or reconfigured. This allows the 
barcode to be used for all existing barcode applications, such as proof of purchase of goods 

25 or services. WAP provides a convenient way for the barcodes to be delivered from the server 
6 and then displayed on the telephone. All known WAP phones (Motorola L-Series+, Nokia 
71 1 0, and Ericsson R320) are able to render web-server originated bar codes. For example. 
Figure 3 shows a Motorola WAP mobile telephone 10 displaying a barcode 1 1. The Figure 
shows a one-dimensional barcode vMch is. capable of encoding a 6 digit number, but two- 

30 dimensional barcodes which can encode 12 or more digit numbers are preferred. The number 
of digits which may be accurately represented by a barcode on a display screen is limited by 
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the resolution of the screen. The higher the resolution, the larger the number of digits that may 
be represented. 

The token niunber is a short-lived number generated by the transaction module 8 of the 
S server 6 on the basis of the transaction details. The token lifetime is limited in order to 
improve security and to ensure that a large number of unused token numbers are available at 
any given time for reuse. Each time the server 6 receives a request for the supplied URL, it 
generates a new token number and barcode at step 56. The server 6 creates a web page 
containing an image of the new barcode and sends it to the phone 2. This web page includes 

10 the Wireless Markup Language (WML) refresh element so that the web page will 
automatically refresh after a specified period of time. This refresh period is chosen to be 
shorter than the token lifetime to allow for access and transmission delays. For example, a 
barcode with a 10 minute lifetime might be automatically replaced with a new barcode after 
8 minutes by including an 8 minute refresh delay within the dynamically generated web page 

15 content. Thus, if the purchaser opens the bookmarked URL, the phone 2 checks to see if the 
barcode is in the phone's cache. If it is in the cache and the page has not expired, step 62, it 
is reloaded from the cache. Otherwise, a request for the URL is passed to the server 6, which 
generates a new token number and barcode at step 56 and transfers it to the phone 2 at step 60. 
While the barcode page remains active on the phone's browser, it is automatically refreshed 

20 at steps 56 to 62 and remains valid. 

The barcode can be used as an entry ticket or to validate or authenticate the holder of 
the phone. For example, purchases of products or services can be effected or validated using 
the barcode on the phone 2, As ^own in Figures 2, 3 and 5, the barcode 1 1 may be read from 

25 the WAP telephone 2 by a barcode reader 12 at step 64. The barcode reading accuracy is 
improved by using a CCD-based barcode reader with a white light source. Alternatively, 
digital video may be used to capture an image of the barcode, allowing the image to be 
processed in software. Once the numeric barcode value has been decoded by the read module 
1 8, it is passed from the computer 14 to the server 6 via the Intemet 4 at step 66. In order to 

30 validate the decoded value, the transaction module 8 of the server 6 checks it against data 
contained in the database 5 at step 68. This validation transaction is also recorded in the 
database 5 at step 70. The server 6 then returns a validation message at step 72 to tiie computer 
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14 which indicates a valid token and instracts the entry gate 16 to open at step 74. 
Alternatively, if the computer 14 and the reader 12 are contained within an integrated device, 
which may be handheld, the device may contain the data required to validate the token, 
eliminating steps 66 and 72. This data could be downloaded from the server 6 prior to each 
5 event. 

Because the token is validated against a database 5 which stores data on each 
transaction, this facilitates extremely flexible ticketing arrangements. For example, many 
different kinds of tokens can be envisaged. Upon validation, a single-use token would be 

10 invalidated for subsequent transactions by recording the validation in the database. 
Alternatively, a multiple-use and/or multiple-vendor token may be validated multiple times 
and possibly by multiple vendors, with specific validations depending upon prior validations, 
the date or time of day, or the elapsed time since the token was generated. For example, a 
single token purchased for a football game could also be used for public transport to and from 

15 the game. The first 100 people who arrive before a certain time by public transport could be 
admitted free. 

In an alternative embodiment, the barcode represents a number which contains 
encoded data so that the barcode is self- validating. The barcode number may be derived from 

20 a number of sources, including the WAP phone number, the date of an event, the vendor 
identification code, and another number within a consecutive set of numbers that may 
correspond for example to nimibered seats. The sources can then be combined and if desired 
encrypted to generate the barcode number. This type of barcode is not short-lived, and may be 
stored in the telephone 2. When the token is to be redeemed for goods or services, the barcode 

25 on the phone 2 is scaimed in the usual way. The barcode is decoded by the reader 12 and 
validated by the computer 14 without reference to the server 6. To validate the barcode 
nimiber, the computer 14 unencrypts the scaimed number or performs a one-way encryption 
of a number derived from the telephone mraiber, the date, time and code of the event (or the 
product code in cases where a good or service has been purchased) for comparison with the 

30 barcode number. If a match is considered to have occurred, the barcode is validated. The 
computer 14 then stores the barcode so that the same barcode may not be reused for the same 
event or purchase. 
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In a further embodiment, the token is delivered to the phone by the SMS message 
mechanism instead of WAP. This mechanism is used with handsets that support picture SMS 
or operator logos (e.g., Nokia 3210, 5110, 5130, 6110, 6130, 6150, 7110, 8210, 8810, 8850 
5 and 9110). Picture SMS can be used to transmit either one- or two-dimensional barcodes, and 
the operator logo mechanism can used to transmit one-dimensional barcode images. 
Alternatively, the GSM SIM Application Toolkit (GSM 1 1.4) may be used to send barcodes 
by SMS, provided that the phone 2 is able to cater for the receipt of SIM Application Toolkit 
image generation instructions. 

10 

A further alternative embodiment could use images downloaded to WAP or HTML 
capable browsers on personal data assistants (PDAs), such as the Palm Pilot™. The advantages 
over WAP telephones are that the screens are more easily read by scanners and that they 
support higher display resolutions. 

15 

The same underlying infiastructure may be used for barcode-based validation and 
smartcard-based validation. In yet another alternative embodiment, the handheld device 2 of 
the validation system is a smartcard rather than a telephone or a PDA. For example, the 
handheld device 2 may be a Chipper® card incorporating ChipperO's ServiceBox technology. 

20 ServiceBox is a middleware layer distributed over the smartcard infrastructure, including the 
card, terminal, security modules, and collection system. ServiceBox enables dynamic 
activation of smartcard ^plications, such as ticketing, via a memory slot mechanism. Once 
allocated, a slot may be used an unlimited number of times. The ServiceBox layer guarantees 
that no other application can change the data stored in the slot It also ensures that the data 

25 stored in a slot has been authorised by a valid security modiile (SAM), so that the data can be 
trusted. The slot remains allocated until it is explicitly released, which also deactivates the 
corresponding application. 

A person wishing to attend an event may purchase a virtual token, as described above. 
30 For example, the person may choose to purchase their token from a web site using their home 
computer 20. Sometime prior to purchasing the ticket, the person registers with a ticketing 
provider. During registration, the person supplies their credit card details and other personal 
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15 



information to the ticketing provider. The person puts their smartcard 2 into a smartcard 
peripheral 22 attached to their home computer, and a unique customer identification number 
(ID) is generated and stored in a newly allocated slot in the smartcard 2. This registration 
procedure only needs to be completed once for a given ticketing provider. Current Chipper® 
cards have a maximum of six slots, restricting their use to a maxunum of sb: different ticketing 
providers concurrently. 

During the registration phase, the person enters their smartcard personal identification 
number (PIN), if any, together with smartcard details collected by a smartcard peripheral, and 
these details are securely submitted to the ticketing provider's server 6. Attached to the server 
6 are a bank of security providers, such as Gemplus GCR410 card readers with dedicated 
security modules (SAMs) for Chipper® cards. The server 6 uses a security provider to generate 
a secure data stream in which a unique customer ID is embedded. This data is sent to the 
person's smartcard peripheral, which writes an entry into a free slot m the card. After 
registration, tiie smartcard 2 may be used to store a virtual token. During the token purchase, 
die person enters the event details together with the unique customer number stored in the slot 
of tiie smartcard 2. The server 6 stores a (customer, event) pair in the database 5. 

Once the customer ID is stored in the smartcard 2, the validation process is essentially 
20 identical to that described above. When the person attends the event, they place their smartcard 
2 in a reader 12 at the validation point. The reader extiacts die data from the conespondmg 
slot in the smartcard 2 and sends it to the vaUdation point computer 14. The validation point 
computer 14 stores a number of event codes for events that it is willing to admit, such as a 
football match, different movies, etc. The validation point computer 14 sends tiie data read 
25 from tiie smartcard 2 and tiie list of event IDs to tiie server 6. If a barcode is used witii a 
handheld device 2 in tins scenario, tiien tiie server 6 ttanslates tiie scanned value to a customer 
ID. However, when tiie handheld device 2 is a smartcard, tiie customer ID read from tiie 
smartcard 2 is transmitted to tiie server 6. The server 6 searches tiie database 5 for a matching 
(customer ID, event ID), given tiie set of event IDs from tiie validation point computer 14. If 
30 a match is found, die server 6 returns tiie match to tiie vaUdation point computer 1 4. indicating 
tiiat tiie token is valid. The token has now been vaUdated. and tiie person is allowed entoy to 
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the event The customer ID remains stored in the slot of the smartcard 2 after validation, and 
may be reused for subsequent events for the same ticketing provider. 

In another application, a person may use the device 2 which includes an integrated 
5 barcode scanner. They may go to a store and fill a trolley with goods from the shelves, 
scanning the barcode of each good with the device 2 as they place it in the trolley. When they 
are finished, they pay for their shopping using the device 2 , and a token is generated for "proof 
of purchase". On the way out of the store, a security guard, acting as the gate 16, scans the 
device 2 to ensure that the shopping was paid for. 

10 

Many modifications will be apparent to those skilled in the art without departing from 
the scope of the present invention as herein described with reference to the accompanying 
drawings. For example, the token may cause generation of a signal, such as sound, to effect 
validation. 
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CLAIMS: 

1 . A token process, including sending a virtual token from a network device to a handheld 
device to generate a machine-readable representation of the token in the handheld device. 

5 

2. A token process as claimed in claim 1 , including reading the representation from the 
handheld device with a reading device to validate said token. 

3. A token process as claimed in claim 1, wherein said machine-readable representation 
10 is produced on a visual display of said handheld device. 

4. A token process as claimed in claim 1, wherein said machine-readable representation 
on said visual display is a barcode. 

15 5. A token process as claimed in claim 1, wherein said handheld device is a mobile 
telephone. 

6. A token process as claimed in claim 1, wherein said handheld device is a personal 
digital assistant (PDA). 

20 

7. A token process as claimed in claim 1 , wherein said handheld device is a smartcard. 

8. A token process as claimed in claim 2, including validation of said token against data 
stored in a network database. 

25 

9. A token process as claimed in claim 2, including validation of said token against data 
stored in said reading device. 

10. A token process as claimed in claim 1, including generating and storing transaction 
30 data for purchase of a product in a network database, said token causing authorisation for 

redemption of said product upon validation against said transaction data. 
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11. A token process as claimed in claims 8, 9 or 10, wherein said validation is dependent 
on previous validations. 

12. . A token process as claimed in claims 8, 9 or 10, wherein said validation is dependent 
5 on time. 

13. A token process as claimed in claim 1 , wherein said sending includes transmitting said 
token using a network communications protocol, such as TCP/IP, SMS, GPRS or, 
WAP. 

10 

14. A token process, including downloading a virtual token from a network device to a 
handheld device to generate a machine-readable representation of the token on the handheld 
device, so that the representation may be read with a reading device to validate said token. 

15 15. A token process including: 

storing transaction data for pvu"chase of a product; 

generating a token for redemption of said product; 

providing access to said token over a commimications network; and 

sending said token to a handheld device on receipt of a request for said token, 
20 said token being readable from said handheld device by a reading device at point of 

provision of said product. 

16. A token process as claimed in claim 15, wherein said handheld device is adapted to 
generate a visual representation of said token for reading by said reading device. 

25 

17. A token system having components for executing the steps of a validation process as 
claimed in any one of the preceding claims. 

1 8. Software stored on computer readable storage media and having code for executing the 
30 steps of a token process as claimed in any one of claims 1 to 17. 
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19, A token system, including a token transmission system for sending a virtual token jfrom 
a network device to a handheld device to generate a machine-readable representation of the 
token on the handheld device. 

5 20. A token system as claimed in claim 19, including a reading system for reading the 
representation from the handheld device with a reading device to validate said token. 

21. A token system including: 

a transaction server accessed over a commimications network, said server storing 
10 transaction data for purchase of a product, and generating a token for redemption of said 
product, said token being accessible over said network from said server such that said token 
is sent to a handheld device on receipt of a valid request for said token from said handheld 
device. 

1 5 22. A token system as claimed in claim 21, including a reading system having a reading 
device for reading said token and causing validation of said token, said reading device being 
at a point of provision of said product 

23. A token system as claimed in claim 22, wherein said product is a good or service, such 
20 as access to facilities or an event or a discount or exchange for currency. 

24. A handheld device includuig wireless communication means for receiving ticket data, 
said ticket data adapted to generate a visual display on said handheld device readable 
by a reading device to redeem a product corresponding to said ticket 



25 



25. A handheld device as claimed in claim 24, wherem said visual display is a barcode. 
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AMENDED CLAIMS: 

1 . (Amended) A token process, including 

generating and storing transaction data for purchase of a product in a network 
5 database; 

sending a virtual token from a network device to a handheld device to generate a 
machine-readable representation of the token in the handheld device; 

reading the representation from the handheld device with a reading device to 
validate said token; and 

10 authorising redemption of said product upon validation of said token against said 

transaction data in said network database. 

2. (Deleted) 

15 3. A token process as claimed in claim 1, wherein said machine-readable 
representation is produced on a visual display of said handheld device. 

4. (Amended) A token process as claimed in claim 3, wherein said machine-readable 
representation on said visual display is a barcode. 

20 

5. A token process as claimed in claim 1, wherein said handheld device is a mobile 
telephone. 

6. A token process as claimed in claim 1, wherein said handheld device is a personal 
25 digital assistant (PDA). 

7. A token process as claimed in claim 1, wherein said handheld device is a 
smartcard. 

30 8. (Deleted) 

9. (Amended) A token process as claimed in claim 1, including validation of said 
token against said transaction data, of said network database, stored in said reading device. 
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10. (Deleted) 

11. (Amended) A token process as claimed in claim 8 or 9, wherein said validation is 
5 dependent on previous validations. 

12. (Amended) A token process as claimed in claim 8 or 9, wherein said validation is 
dependent on time. 

10 13. A token process as claimed in claim 1, wherein said sending includes transmitting 
said token using a network communications protocol, such as TCP/IP, SMS GPRS or 
WAP. 



15 



14. (Amended) A token process, including downloading a virtual token from a network 
device to a handheld device to generate a machine-readable representation of the token on 
the handheld device, so that the representation may be read wdth a reading device to 
validate said token, said token being validated on the basis of transaction data of a network 
database. 

20 15. A token process including: 

storing transaction data for purchase of a product; 
generating a token for redemption of said product; 
providing access to said token over a communications network; and 
sending said token to a handheld device on receipt of a request for said token, 
said token being readable from said handheld device by a reading device at point of 
provision of said product. 

16. A token process as claimed in claim 15, wherein said handheld device is adapted to 
generate a visual representation of said token for reading by said reading device. 



25 



30 



1 7. A token system having componems for executing the steps of a validation process 
as claimed in any one of the preceding claims. 
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18. (Amended) Software stored on computer readable storage media and having code 
forexeoutrngtirestepsofatokenprocessasoiaimedinanyoneofclaims , .0 ,6. 

v.nua> token from a ne^voric device to a handi>e,d device U, generate a machine-readable 

I T , ; °" of said 

product upon vahdatron of said token on the basis of transaction data in said token 

transmission system. i"xs.cii 



10 20 



A token system as claimed in claim 19. including a reading system for readmg fte 
.presentafon from the handheld device with a reading device to validate said token. 

21. A token system including: 

a ttansacion server accessed over a communicadons network, said server storing 
data for purchase of a p^duct. and generating a token for redemption of 
product, sard token being accessible over said network from said server su^ 



H " ■"^^^ 21. including a reading system having a 

^dmg dev.ce for reading said token and causing vaUdation of said tokl. said JLg 
device bemg at a point ofprovision of said product. 



25 



30 



23. 



A token system as claimed in claim 22. whe,.i„ said product is a good or service 
such as access to facilities or an event or a discount or exchange for currency. 

24. (Amended) A handheld device including wireless communication m«ms for 
recetvmg ttcke. data from a communications network, said ticket data adapted to grer^ 
a vsual d.play on said handheld device readable by a reading device to r^eem a Z^c 
co^espondmg to said ticket data upon validation of said ticket data on ti,e Wo 
transaction data in said communications network. 



25. 



A handheld device as claimed in claim 24, wherein said visual disptay is a bar^de. 
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26. O^ew) A token process as claimed in any one of claims 1 to 16, wherein said token 
IS val.d for a predetermined time determined by said transaction data. 
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